Ad-hoc service discovery protocol

ABSTRACT

An ad-hoc discovery protocol improves reliability, security and scalability of multicast and server-based discovery. In switching from multicast to server-based discovery, the discovery client is made responsible for multicast suppression, and not discoverable devices with services. Messages include message identifier and time-to-live parameters to detect recast queries and avoid duplicating replies. A device&#39;s announcement message includes endpoint identifier, configuration number and stateless boot time parameters to detect changed device configuration and rebooted state for refreshing cached device and service descriptions. Paging parameters allow a discovery client to control the number of discovery responses returned at a time from a discovery server.

COPYRIGHT AUTHORIZATION

[0001] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by any one of the patentdisclosure, as it appears in the Patent and Trademark Office patentfiles or records, but otherwise reserves all copyright rightswhatsoever.

TECHNICAL FIELD

[0002] The present invention relates to network communications protocolsfor discovery of devices and services on a data network.

BACKGROUND

[0003] Various discovery protocols have been proposed to enable a device(e.g., a user-operated device) to discover other devices and services onmanaged and unmanaged (ad-hoc) networks, without prior knowledge of theother devices and services. Examples include the Service LocationProtocol, version 2 (SLPv2), described in Guttman et al., “ServiceLocation Protocol, Version 2,” IETF RFC 2608, June 1999; Rendevous byApple Computer, Inc., described in Chesire, “DNS-based ServiceDiscovery,” IETF Internet Draft, December 2002 and Chesire, “PerformingDNS queries via IP Multicast,” IETF Internet Draft, December 2002; andthe Simple Service Discovery Protocol (SSDP), described in Goland etal., “Simple Service Discovery Protocol/1.0, Operating without anArbiter,” IETF Internet Draft, April 2000. For various reasons, theseother discovery protocols suffer limitations as to reliability, securityand scalability.

SUMMARY

[0004] An ad-hoc service discovery protocol described herein improvesupon other service discovery protocols in areas of reliability, securityand scalability. The ad-hoc service discovery protocol generallyinvolves 3 kinds of actors on a network: discovery clients (e.g., acontroller, or like device seeking to discover services to control onthe network), discovery responders (e.g., devices and services ondevices, but possibly also controllers), and optionally a discoveryserver.

[0005] The described ad-hoc service discovery protocol supportsserver-based discovery (such as in an administered network of anenterprise or office environment), and defaults to multicast discoveryin ad-hoc networks. For improved network scalability, the discoveryclient discovers and uses a discovery server if present, and otherwiseresorts to multicast-based discovery. The discovery device simplyresponds to all matching discovery requests, whether from a discoveryclient or from a discovery server. This eliminates having the deviceswitch modes from multicast-based to server-based discovery; if thedevice were to switch to a server-based mode and not notice failure ofthe discovery server, the device would be invisible from multicast-baseddiscovery. In some described implementations, the ad-hoc servicediscovery protocol may also support a configured mode where devices canbe configured to respond only to discovery from a discovery server.

[0006] The described ad-hoc service discovery protocol further enhancesreliability and security by transmitting direct messages (e.g.,discovery responses, and discovery requests directed to the discoveryserver) using the Transmission Control Protocol (TCP), rather than UserDatagram Protocol (UDP). Unlike UDP, TCP guarantees delivery as well asorder of delivery.

[0007] The described ad-hoc service discovery protocol also improvesscalability of retransmitting (recasting) multicast messages. Themessages have a header that includes a message identifier andtime-to-live (TTL) parameter specifying a time interval over which themessage may be recast. A discovery responder can then determine if amessage to which it had previously responded is being recast, and avoidduplicating its response. In comparison, some other protocols requirethe discovery client to include “an already responded list” whenrecasting its discovery message, which identifies any discoveryresponders whose response it received. Such already responded listsincrease the size of discovery messages, and increase message processingresource requirements, which limits scalability.

[0008] The described ad-hoc service discovery protocol further improvesscalability and reliability by using an endpoint identifier,configuration number and stateless boot time in announcement messages ofa service or device. The endpoint identifier is a unique identifier ofthe respective service or device.

[0009] The configuration number enables controlled caching of thedescription of the service or device. The configuration number isassociated with the configuration of the service or device. If theconfiguration changes, then the configuration number also changes. Whenthe announcement message is received, the recipient (e.g., discoveryserver or discovery client) can use the endpoint identifier to check forthe presence of a cached description of the service or device in itslocal cache. The recipient then compares the configuration number tocheck whether the cached description is up to date. If the cached copyis current, the recipient does not need to further contact the device toretrieve its full description, which improves scalability.

[0010] The stateless boot time represents the stateless boot time of theservice or device. When the device reboots in such a way as to lose itsstate, the stateless boot time updates (e.g., as a clock value orincremented boot counter). This allows the discovery client or discoveryserver to detect that the client has been rebooted, which then allowsthe discovery client or server to re-establish event subscriptions orlike features that may be affected by the device's loss of state.

[0011] The described ad-hoc service discovery protocol also supportshierarchical scopes. The description of a service or device can specifya scope that identifies one or more associated logical or physicalgroupings of services or devices. A discovery server also can specifysupported scopes for which it manages discovery on the network. Adiscovery client's discovery request (called a “find message”) canoptionally specify a scope.

[0012] Descriptions of services and devices in the described ad-hocservice discovery protocol are based on schemas that are taxonomized.For example, the schema of devices is based on that of services. Aschema of a particular kind of device (e.g., a printer) is based on theschema for devices.

[0013] The described ad-hoc service discovery protocol further providessupport for filters and paging in discovery queries. If a query involvesa combination of properties to be matched in device or servicedescriptions, the discovery client can express the desired combinationusing a filter query parameter.

[0014] Further, the discovery client can use parameters in its discoveryquery to retrieve a single “page” amount of responses at a time from thediscovery server (which, for example, can be a number of entries thatcan be displayed as a page by the discovery client). In oneimplementation, the discovery client can specify a size limit and pagecontext in its discovery query. The discovery server responds with up tothe size limit of matching entries in its cache of service and devicedescriptions, and returns the page context and status indicating whetherthe query is complete. The discovery client can continue to requestfurther “pages” in subsequent queries using the size limit and returnedpage context.

[0015] Additional features and advantages of the invention will be madeapparent from the following detailed description of embodiments thatproceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016]FIG. 1 is a block diagram of a network architecture in which anad-hoc discovery protocol is used.

[0017]FIG. 2 (including parts A-B) is a listing of an XML schema in WebServices Description Language (WSDL) format defining web servicesoperations for messages in the ad-hoc discovery protocol.

[0018]FIG. 3 (including parts A-F) is a listing of an XML schemadefining message types in the ad-hoc discovery protocol.

[0019]FIG. 4 is a listing of an example response containing adescription of an example device.

[0020]FIG. 5 is a listing of an example find message in the ad-hocservice discovery protocol.

[0021]FIG. 6 (including parts A-B) is a listing of an example findresponse message in the ad-hoc service discovery protocol.

[0022]FIG. 7 is a listing of an example announcement message in thead-hoc service discovery protocol.

[0023]FIG. 8 is a listing of an example bye-bye message in the ad-hocservice discovery protocol.

[0024]FIG. 9 is a pseudo-code listing of a procedure for a discoveryresponder to send an announcement message in the ad-hoc servicediscovery protocol.

[0025]FIG. 10 is a block diagram of a suitable structure of computingdevices for the network device architecture of the ad-hoc servicediscovery protocol of FIG. 1.

DETAILED DESCRIPTION

[0026] The following description is directed to improvements in ad-hocdiscovery protocols. An exemplary application of an ad-hoc servicediscovery protocol incorporating these improvements is in a networkenvironment of devices using a version of the Universal Plug and Play(UPnP) peer device networking protocol (e.g., as a replacement for theSSDP discovery protocol used in UPnP, version 1). UPnP is described inmore detail in “Universal Plug and Play Device Architecture, version1.0,” Microsoft Corporation, Jun. 8, 2000; and “UPnP™ DeviceArchitecture 1.0, version 1.0.1,” UPnP Forum, May 6, 2003 (bothdocuments being available from the UPnP Forum through its website atwww.upnp.org). However, the improved ad-hoc service discovery protocolis not limited in application to use with UPnP, and can be adapted orapplied for discovery in other computing and networking environments andapplications.

[0027] General Networked Device Architecture Overview

[0028]FIG. 1 illustrates a network architecture 100 in which the ad-hocservice discovery protocol can be used. This network architecture 100can be an arrangement of UPnP-compliant networked computing devices. Asdescribed for example in “UPnP™ Device Architecture 1.0, version 1.0.1,”UPnP Forum, May 6, 2003, the UPnP device architecture involves two typesof actors: devices, hosting UPnP-compliant services; and control points(or more simply controllers), who control the use of the services. TheUPnP protocol lets controllers discover the devices and services hostedon the devices. There also may be cases involving discovery of thecontrollers, e.g., to establish security credentials. Further, there arealso occasions in which connectivity between the devices is aserver-based operation.

[0029] The network architecture 100 of the ad-hoc service discoveryprotocol generally engages three kinds of actors:

[0030] Discovery responders 130-132, usually devices and services ondevices, but possibly controllers.

[0031] Discovery clients 110-111, usually controllers.

[0032] And, optionally discovery servers 140.

[0033] These actors are networked via a network 120 or networks, such asnetwork wiring (e.g., for an Ethernet or other local area network (LAN),a home phone line or power line network, a Firewire (IEEE 1394),universal serial bus (USB), or etc.), fiber optic cabling, wirelesstransceivers (e.g., for a Bluetooth, Wi-Fi (IEEE 801.11b), or otherwireless data network) or the like. The network 120 can encompass apersonal area network of devices carried by or worn on a person, a localarea network of devices in a locale, or a wide area network (such as theInternet or other geographically dispersed data network).

[0034] The discovery clients 110-111 and responders 130-132 can be anyvariety of device with embedded computing and networking capabilities,including without limitation audio/video or other multimediarecording/transmitting/receiving/or presenting device (broadcastreceivers, televisions, video players, cameras, etc.), computers(personal, workstation, server, handheld, laptop, tablet, or othermobile), telephones, office equipment (printers, copiers, scanners,fax), security systems, home appliances (lighting, heating, ventilation,air conditioning, door openers, kitchen appliances, etc.), as a fewgeneral examples.

[0035] The discovery clients 110-111 and responders 130-132 eachimplement the ad-hoc service discovery protocol. They include networkingprotocol stacks for communicating over the network 120 with othernetwork actors. They also include network interfaces for interfacingwith the network 120. In general, the network interfaces 150-153 are thephysical or hardware interfaces to the networks, such as a networkinterface card (NIC) or adapter for physically interfacing with thenetwork media. The devices also can include various logical interfacesprovided over a physical network interface, such as a virtual privatenetwork (VPN), unicast, Point-To-Point Tunneling Protocol (PPTP) on asingle NIC.

[0036] In one implementation, the ad-hoc service discovery protocol isbased on XML Web Services of Microsoft Corporation, as described in,among others, Christensen et al., “Web Services Description Language(WSDL) 1.1,” W3C Note 15 Mar. 2001; and R. Wolter, “XML Web ServicesBasics,” Microsoft Corporation, December 2001. As such, the ad-hocservice discovery protocol also uses the networking protocol stack ofWeb Services, which also can serve the needs of discovery, control andeventing. This simplifies the implementation of devices in the networkarchitecture 100. Further, the ad-hoc service discovery protocol canthen reuse the security framework defined in Web Services Security(WS-Security), described in Atkinson et al., “Web Services Security(WS-Security), Version 1.0, April 2002, again simplifying deviceimplementation.

[0037] Although illustrated as having a single discovery server 140, theenvironment 100 can include multiple discovery servers (e.g., discoveryservers with divided responsibility over different scopes of discoveryresponders in the environment).

[0038] Ad-Hoc Service Discovery Protocol Overview

[0039] In one implementation, the ad-hoc service discovery protocoldescribed herein provides transport-neutral mechanisms to locate devicesand services. The ad-hoc service discovery protocol involves exchangesof four basic message types between discovery clients, discoveryresponders and discovery servers, including: find, find response,announce, and bye-bye.

[0040] The ad-hoc service discovery protocol can operate in two modes:either by sending a query (a find request message) to a multicast group,or by sending a query directly to a selected discovery server. Inmulticast mode, the devices whose device or service description matchesthe query return a response (a find response message) directly to thesender; in direct mode, the server provides a list of devices orservices matching the query. The procedure by which clients discoverservers and switch from multicast to server-based operation is called“multicast suppression.”

[0041] Devices send an announcement (an announce message) when theyenter a network; they may send a departure notice (a bye-bye message)when they are ready to leave a network.

[0042] Discovery responses may only return the essential characteristicsof the devices and services, such as the service identifier and theaddress at which the service is reachable; other procedures can be usedto obtain devices characteristics, such as by directly querying thedevice.

[0043] Common Formats

[0044] The ad-hoc service discovery protocol uses several ExtensibleMarkup Language (XML) formats for its message exchanges. XML isdescribed more fully in Bray et al., “Extensible Markup Language (XML)1.0 (Second Edition),” W3C Recommendation, October 2000.

[0045] Common Header Blocks.

[0046] The ad-hoc service discovery protocol defines a small number ofcommon SOAP-based header blocks that are common to some or all of thefour message types. Simple Object Application Protocol (SOAP) isdescribed in Box et al., “Simple Object Application Protocol (SOAP)1.1,” W3C Note 8 May 2000. These header blocks are used to provide basicmessage delivery and correlation functionality. Alternativeimplementations of the ad-hoc service discovery protocol need not usethese message blocks.

[0047] MessageID.

[0048] This header block contains a uniform resource identifier (URI)that uniquely identifies this transmission unit. When retransmitting amessage, the same URI must be used. It is defined in the. XML schemashown in FIG. 3C.

[0049] CorrelationID

[0050] This header block contains a URI that uniquely identifies themessage that this transmission unit is a response or fault to. It isdefined in the XML schema shown in FIG. 3C.

[0051] Idempotent.

[0052] This header block is always empty and its presence in a SOAPmessage indicates that the request may be treated as idempotent. It isdefined in the XML schema shown in FIG. 3C.

[0053] TTL.

[0054] This header block contains a value (a 32-bit integer) thatindicates the number of seconds that this transmission unit is to beconsidered viable. It is defined in the XML schema shown in FIG. 3C.

[0055] To.

[0056] This header block contains a URI that indicates the intendedrecipient of the message. It is defined in the XML schema shown in FIG.3C.

[0057] ReplyTo.

[0058] This header block contains two elements both of which contain aURI. Presence of this header block indicates the intended recipient forany responses or faults for the current message. The contents of the“to” child element should be copied to the “To” SOAP header block of theresponse or fault message that is sent to the transport addressspecified by the “transportAddress” child element. It is defined in theXML schema shown in FIG. 3C.

[0059] WS-Policy Assertion Types

[0060] The ad-hoc service discovery protocol uses a Web Services policyassertion (WS-Policy) to express security and transport capabilities andrequirements. (See, e.g., Box et al., “Web Services Policy Framework(WS-Policy),” Version 1.1, May 2003.) This section defines one policyassertion type to indicate the transport type and address of a service.

[0061] Address Policy Assertion.

[0062] This policy assertion type contains a URI that indicates thetransport-specific address. The type of transport is derivable from theURI scheme of the address. This assertion is defined in the XML schemashown in FIG. 3D.

[0063] Devices and Services Description.

[0064] The purpose of the ad-hoc service discovery protocol is to letdiscovery clients discover services hosted by devices. The data model isthus device centric: a device hosts services, or possibly other devices;the find responses will carry a description of the device and of all thehosted services.

[0065] The key data structures in the model are the “ServiceEntry,” usedto describe services, and the “DeviceEntry,” used to describe devices,which are defined in the XML schema shown in FIG. 3E-F. The“ServiceEntry” schema consists of the following strongly typed elements:

[0066] friendlyName: Friendly name of the service (or of the device),

[0067] configNumber: An optional 32 bit unsigned integer representingthe configuration sequence number that is incremented every time theservice configuration is modified.

[0068] scopes: An optional list of scopes with which the service hasbeen associated

[0069] endpointInfo: Information needed to contact the serviceencapsulated in an instance of “EndpointInfo” schema type, whichincludes:

[0070] endpointID: Unique identity of the service,

[0071] implementation Type: Identifies the concrete implementation typeof the service,

[0072] typeInfo: List of WSDL 1.1 portTypes supported by the service,

[0073] policy: A WS-Policy policy expression that conveys, among otherthings, the supported transports and security policy related toauthentication, encryption, and integrity enforced by the service,

[0074] An optional list of deployment-specific properties as anextensibility mechanism.

[0075] The “service type” key specified in the Find request can matchthe types specified in the “implementation Type” and “typeInfo” elementsof the “endpointInfo” type.

[0076] The devices are described using a superset of the servicedescription. In the XML schema, the DeviceEntry schema type extends theServiceEntry schema type by adding three elements:

[0077] manufacturerName: Device manufacturer name

[0078] serialNumber: Device serial number

[0079] entries: An optional list of deviceEntry or serviceEntry elementsrepresenting contained devices or services.

[0080] The discovery server is described by a “DiscoveryServiceEntry”schema type (in FIG. 3E) that extends the “ServiceEntry” by adding thefollowing element:

[0081] supportedScopes: list of scopes supported by the discoveryserver. In other words, clients can utilize this discovery server tosearch for services and devices that are associated with the scopesspecified in the supported scopes. The “supportedScopes” is orthogonalto the “scopes” element of the “ServiceEntry” that indicates the scopeswith which the discovery device itself is associated.

[0082] In addition, the discovery server supports the “DiscoveryServer”port type.

[0083] The XSD definition of the ServiceEntry, DeviceEntry andDiscoveryServiceEntry schemas are shown in FIG. 3E-F.

[0084] The configuration sequence number (configNumber) is used toenable controlled caching of device or service characteristics. When adevice joins the network 120 (FIG. 1), its Announce message contains thedevice identifier (the endpointID field in the endpointInfo element),the configuration number, and the stateless boot time of the device; therecipients (e.g., discovery clients 110-111 and discovery server 140 (ifpresent)) of the message can use the unique identifier to check thepresence of a device description in their local cache, and theconfiguration number to check whether their copy is up to date; if thelocal cached value is up to date, they will not need to further contactthe device. A configuration number may also be associated to a servicehosted by a device; if a service configuration changes, then theconfiguration number of the hosting device must also change. If acontained service or device inherits properties from the containingdevice and these inherited properties change, then the configurationnumber of the contained service or device must also change. However theconverse is not true; when a containing device's configuration numberchanges, the configuration of contained devices or services may beunchanged if their specific configuration is unchanged.

[0085] The scope information is used to control the scope of queries inlarge networks. It can be set by an explicit configuration of a device,or it can be associated to the device identifier in the database of adiscovery server. A device may be present in multiple scopes. Bydefault, UPNP services (and contained devices) are listed under the samescope as their hosting devices; however, it is possible to assigndifferent scopes to individual services (and contained devices). Thescope value is encoded as a URI, such as“http://example.com/loc/bldg2/floor1.” Scopes defined using “http” URIare hierarchical and thus support prefix matching. In other words, ascope string in a Find message which is a prefix for a configured scopeof a device/service should match. However the opposite is not true. Forexample if a device has a configured scope of“http://example.com/loc/bldg2/floor1,” then a Find with scope of“http://example.com/loc/bldg2/” should match, but a Find with scope of“http://example.com/loc/bldg2/floor1/room32” should not match. Ifmultiple scope URIs exist, then the scope URI specified by the Find canmatch any one of them using the rules outlined above. For example if adevice has 2 scope strings “http://example.com/loc/bldg2/floor1” and“http://example.com/org/us/sales,” and a Find is issued with“http://example.com/loc/bldg2/floor1,” then the scopes should match. Adevice which has not been configured to have a particular scope shouldby default have a scope of“http://schemas.upnp.org/2003/01/discovery/adhoc.” Discovery clientsthat do not specify any scope strings in the Find message will matchonly with devices with a scope string of“http://schemas.upnp.org/2003/01/discovery/scope/adhoc.” Discoveryclients that specify a scope string of“http://schemas.upnp.org/2003/01/discovery/scope/any” in the Findmessage will match with all scopes.

[0086] The “endpointInfo” element is used to describe thecharacteristics of a service or a device. It contains all of theparameters required to establish a connection to the service, such astransport addresses or security policy. The endpointID component of theendpointInfo is a unique identifier of the service; it is also used toidentify the device when the service represents a device.

[0087] The implementationType element identifies the type of theservice, a single URI that may identify the combination of a complex setof types. The complete list of types that can be used to access theservice is provided in the typeInfo element.

[0088] The policy element that contains two or more types of policyassertions: transport policy assertions are the list of transport typesover which the service can be reached, and for each transport thecorresponding address. The transport data depends on the transport type,but is typically represented as a URL for most common IP transports suchas TCP, HTTP, and SMTP. Security policy assertions document thesupported authentication, encryption, and signature algorithms. Otherassertions may be included to characterize other, service-specificrequirements.

[0089] It is not necessary to document the transport policy and securitypolicy for a service or device that is contained in another device, ifthe values are the same as those of the containing device, and if theendpoint reference of the containing device is included in the samemessage. In fact, the only required field in the EndpointInfo schematype is the endpointID field representing the identity of the service;the rest are optional. An EndpointInfo instance containing only theendpointID field can only be used for identity comparison and needsfurther resolution to be able to contact the service identified. Thediscovery “Find” message can be used to refine such a minimalEndpointInfo instance to specify the transport addresses over which itcan be reached. In other words, all the EndpointInfo instances returnedas part of the FindResponse message should minimally specify theendpoint identity and the transports fields. However, services anddevices should include as much information as possible and permissiblein the FindResponse message in the interest of efficiency. The elementspublished in the FindResponse message remain the same across multiple“Find” requests unless the config number has changed; some elements maybe omitted from some responses, e.g. for security considerations. Once atransport address is known over which the identified service can bereached, the EndpointInfo instance can be further refined to the desiredlevel by contacting the service directly.

[0090] Both the ServiceEntry and the EndpointInfo schema types containan extensibility option.

[0091] The ServiceEntry and DeviceEntry schema types can also beextended by the definition of a more specific service or device datatype. For example, it is possible to define a “PrinterCopierDeviceEntry”schema type as an extension to the base “DeviceEntry” schema type thatadds “color”, “supportedPaperSizes”, and “supportedOrientations” fields.In addition to providing the benefits of strong typing, informationspecified in a schema can be queried more easily and readily using afilter expression (in XML Path Language (XPath) format as described inClark et al., “XML Path Language (XPath) Version 1.0,” W3CRecommendation 16 Nov. 1999).

[0092]FIG. 4 shows an example response of a complete description of ahypothetical printer-copier device; it contains the fields specified bya hypothetical printer-copier entry schema called“PrinterCopierDeviceEntry”. This description describes a printer-copierdevice that aggregates printer and copier services of types XPrinter andXCopier respectively. The services are reachable on separate transportaddresses that are different from the containing device, but share thesame security policy as the containing device. The printer-copier deviceis capable of printing and copying in color, supports A4 and Legal papersizes, and supports Portrait and Landscape orientations.

[0093] Message Formats

[0094] The ad-hoc service discovery protocol uses four types ofmessages, implemented using SOAP; error reporting follows the SOAPspecification. The “Find” message is used to start a query; the“FindResponse” message carries the responses to this query; the“Announce” message is sent by a discoverable entity when entering anetwork, and the “Bye-Bye” message may be sent by a device about todepart a network. All these messages refer to elements of the device andservice description.

[0095] Find Message.

[0096] When discovery clients 110-111 (FIG. 1) want to discover objectson the network 130 (FIG. 1), they prepare a FIND request, send it, andwait for responses. In ad hoc mode, the find request is sent to adiscovery multicast address (which may be an Internet Protocol version 4(IPv4) or Internet Protocol version 6 (IPv6) address, or both). Inserver mode, the find request is sent to the URL of the discovery server140 (FIG. 1).

[0097] The request has two parts: addressing and transport controlelements encoded in the SOAP header, and a query specification sent inthe body of the SOAP request. The key elements in the SOAP header are:

[0098] The endpoint URI to which the message is sent, which can beeither the URI of the server, or a discovery URI,

[0099] A unique identifier of the request, used for correlating requestsand responses and for detecting duplicate requests,

[0100] An optional “ReplyTo” value, identifying the endpoint at whichthe originator of the query expects to receive responses.

[0101] The query specification can contain:

[0102] An optional scope indication,

[0103] An optional “key” specification, providing a compact encoding ofsimple queries by specifying the well known property name, and aproperty value.

[0104] An optional “filter” specification, encoding a rich query usingas a combination of XPATH values,

[0105] An optional “findContext” specification, encoding the contextassociated with find request processing,

[0106] An optional “sizeLimit” indication,

[0107] An optional “pageContext” indication.

[0108] A scope parameter indicates that a discovery client is onlyinterested in objects that belong to the specified scope.

[0109] The key specification is used for simple queries, in which thediscovery client 110-111 is looking up a single property of thediscovery responder 130-132, such as a service type or its identifier.The property is identified by a simple type. The discovery respondersrecognize the following three simple types defined in the schema shownin FIG. 3A:

[0110] Type: Its value specifies a service type

[0111] DeviceType: Its value specifies a device type

[0112] EndpointID: Its value specifies the unique identifier of aservice/device

[0113] The desired property is expressed as a character string, whichmay represent either the value itself; or a prefix of that value.

[0114] A query can contain only one key specification. If a search on acombination of parameters is desired, the client should express thedesired combination using the “filter” parameter. Simple discoveryresponders, such as simple discovery devices, may not be able to processcomplex filters; responders may consider a filter expression that theycannot fully evaluate as true, and return a response even if they arenot sure that this response actually matches the query.

[0115] The query can be supplied with an optional context parametercalled “findContext” that can be used for encoding application semanticssuch as supplying additional context to a filter specification,request-response correlation, etc. It is composed of two parts, both ofwhich are typed as “xs:anyType”. The first part called “filterContext”is used for query message processing. The second part called“callbackContext”, if present, is not interpreted in the query messageprocessing, but is emitted back as the “callbackContext” parameter intothe response message. In other words, the “filterContext” is used in thequery request processing and the “callbackContext” is used in the queryresponse processing.

[0116] If a query does not contain a key specification or a filterspecification, it will return all-objects in the specified scope. If aquery that does not contain a scope specification, it will apply only tothose objects that have either not been configured with a scope value orhave been explicitly configured as belonging to the “/adhoc”, scope.

[0117] When the discovery client 110-111 is sending the find request toa discovery server 140, the discovery server may sometimes find a verylarge number of matching entries in its database. There will be cases inwhich either a discovery client or a discovery server wants to limit thenumber of entries that will be returned in a response. A discoveryclient requests only the first N objects matching its Find criteria bysetting the value of the optional sizeLimit element of its Find request.A discovery server will report the non completion of the query in thestatus element of the Find Response, as explained in the discussion ofthe find response message below.

[0118] In other cases, a discovery client is interested in more entriesthan a typical FindResponse will allow or that the discovery client iswilling to process at once; the complete set of entries will beretrieved by a cycle of Find requests and Find Response. To support thisscenario, a discovery client may request paged results when it directs aFind request to a directory server by including a pageContext element inthe Find message:

[0119] The first Find request will carry an empty pageContext element,

[0120] The subsequent Find requests will carry a pageContext elementcopied from the last FindResponse;

[0121] The client must specify a value for sizeLimit when supplying apageContext; the subsequent Find request must carry the same filter, keyand scope parameters as the first one.

[0122] The cycle will terminates when the client receives a FindResponsein which the pageContext element is empty; a non empty pageContextindicates that more pages are available. If more pages are available butthe discovery client is not interested in retrieving them, the clientshould send a Find request with the original parameters, sizeLimit=“0”,and the pageContext from the last FindResponse in the sequence; thisallows the directory server to immediately free any resources it mightbe consuming that would allow retrieval of the next page of results.

[0123]FIG. 5 shows an example of a find request that is sent to themulticast channel:

[0124] Because sending lengthy find messages over multicast isinefficient, and prone to failure, senders in multicast mode preferablykeep the message size under 1400 bytes, which is a practical payloadlimit on common local area networks.

[0125] Find Response Message.

[0126] In ad hoc mode, a discovery responder 130-132 (FIG. 1) thatreceives a query sends a response if the query matches one of thelocally available services. In server mode, the discovery server 140(FIG. 1) returns a response containing a list of the objects that matchthe service. The query response is encoded as a SOAP message, which issent to the “ReplyTo” endpoint specified in the query if one wasspecified, and to the originator itself otherwise. The response is sentover a reliable protocol (e.g., TCP), even if the query was received viaUDP.

[0127] The find response message has two parts: addressing and transportcontrol elements are encoded in the SOAP header, and the response datais sent in the body of the SOAP request. The key elements in the SOAPheader are:

[0128] The endpoint URI to which the message is sent, copied from the“to” element of the “ReplyTo” SOAP header component of the query'sheader,

[0129] A unique identifier of the response,

[0130] A correlation element that repeats the identification of thequery, The response body contains:

[0131] A list of entries describing the discovered objects, followingthe ServiceEntry schema used to represent a service and “DeviceEntry”schema type used to represent a device,

[0132] The optional callbackContext if it was specified in the Findrequest,

[0133] An optional status element,

[0134] An optional pageContext element,

[0135] The status element provides information when a Find request hasbeen processed, but the processing was not successful. The status schemaconsists of the following elements:

[0136] details: contains a machine-interpretable payload and isspecified to be of “anyType”

[0137] description: an optional element that contains additionalhuman-readable information about the failure.

[0138] The pageContext element is present when the client included apageContext in the Find request, and is used to enable “continuationrequests” as explained in the discussion of the find message above. ThepageContext content returned with a given FindResponse must be passedback to the discovery server (along with the original parameters,including the filter, scope, etc.) on the next Find in order for theclient to receive the next sizeLimit objects in the result set. ThepageContext may change from page to page of a given sequence ofFind-FindResponse messages, and the discovery client may send thepageContext from only the most recent FindResponse in the sequence inits next Find request. Specifying a previous pageContext value may yielda failure status with <details xsi:type=“disc:InvalidPageContext”/>child. If the pageContext in the most recent FindResponse is empty, thatFindResponse holds the last objects in the result set.

[0139] In this implementation, a FindResponse with a pageContext neverincludes a status element with <detailsxsi:type=“disc:SizeLimitExceeded”/> child.

[0140]FIG. 6 shows an example response illustrating the typicalinformation received in response to the Find request shown above. Sincethe request is for a printer type, the response data contains the fieldsspecified by an example printer-copier entry schema called“PrinterCopierDeviceEntry” shown in FIG. 4.

[0141] The above response indicates a printer-copier device thataggregates printer and copier services of types XPrinter and XCopierrespectively. The services are reachable on separate transport addressesthat are different from their containing device, but share the samesecurity policy as their containing device. The printer-copier device iscapable of printing and copying in color, supports A4 and Legal papersizes, and supports Portrait and Landscape orientations.

[0142] Announce Message.

[0143] The announce message is sent by a discovery responder 130-132upon entering a network. In the absence of explicit configuration, themessage is sent to the same multicast address as queries. In someenvironments, devices and controllers can be configured to send thismessage at the specific address of a discovery server, denoted by adiscovery server's URL. Only the root device of the discovery responder130-132 (not its hosted services) sends the announce message when itenters the network. More precisely, it is not necessary to announce thedevices/services aggregated by the root device unless there is anexplicit reason to do so such as a configuration change in theaggregated device/service.

[0144] The announce message has two parts: addressing and transportcontrol elements encoded in the SOAP header, and an announcement datasent in the body of the SOAP request. The key elements in the SOAPheader are:

[0145] The endpoint URI to which the message is sent, which can beeither the URI of the server, or a conventional discovery URI formulticast transmission,

[0146] The “contact” URI to which discovery clients can send directqueries,

[0147] A unique identifier of the request,

[0148] The announce body contains the unique identifier of the discoveryresponder, its configuration number, and the value of thestatelessBootTime for the device:

[0149] The unique identifier is set to the value of the endpointID fieldin the endpointInfo element of the service/device entry;

[0150] The configuration number is set to the value of the configNumberelement of the service/device entry;

[0151] Discovery servers 140 and discovery clients 110-111 utilize theunique identifier and configuration number of the discovery responder tocheck if they have the latest information about this service/device. Ifnot, they may issue a unicast Find request with the key specificationindicating a lookup for a specific endpoint id, and the looked up keyvalue is set to the unique identifier of the discovery responder. Theservice will respond to the Find request by supplying its configurationas explained in the FindResponse section above.

[0152] The “StatelessBootTime” represents the stateless boot time of theservice/device. In one implementation, the stateless boot time is avalue expressed according to a monotonically increasing clock, andencoded as a 32 bit integer. This field is used to detect the case whena service/device has gone down and come back up again and can be used byclients for features such as reestablishing desired event subscriptions.A convenient mechanism is to set this field to the boot time of thedevice, expressed as seconds elapsed since midnight Jan. 1, 1970; fordevices that have a notion of time, this will not require any additionalstate to remember or be “flashed.” However, it is perfectly acceptablefor a service to reuse a simple boot counter that is incremented onevery stateless boot as a value of this field if such a boot counter isneeded for its functionality. As such, the discovery clients should notview this field as a timestamp. The service should not change this fieldvalue when it goes down and comes back up without loss of state.

[0153]FIG. 7 shows an example of an announcement message.

[0154] ByeBye Message.

[0155] The ByeBye message is sent by a discovery responder 130-132(FIG. 1) when it is ready to depart the network 120. In the absence ofexplicit configuration, the message is sent to the same multicastaddress as queries. In some environments, devices and controllers can beconfigured to send this message at the specific address of a discoveryserver, denoted by a server's URL.

[0156] The response has two parts: addressing and transport controlelements encoded in the SOAP header, and an announcement data sent inthe body of the SOAP request. The key elements in the SOAP header are:

[0157] The endpoint URI to which the message is sent, which can beeither the URI of the server, or a conventional discovery URI formulticast transmission,

[0158] A unique identifier of the request,

[0159] The response body contains the unique identifier of the discoveryresponder, and the same stateless boot time that was sent in thecorresponding announce message.

[0160]FIG. 8 shows an example of a ByeBye message.

[0161] Roles and Behavior

[0162] The WSDL specification in FIG. 2 and the XML Schema specificationin FIG. 3 capture the message format and the specification of thevarious operations. In this section, the behavior of the systemsinvolved in discovery is defined, such as the use of configurationinformation, multicast and unicast transmission, and the use of timers.

[0163] In one implementation, the ad-hoc service discovery protocol usesthe following parameters (alternative implementations can vary theseparameters):

[0164] PORT: a port number to be allocated by the IANA for the operationof the ad-hoc service discovery protocol. Discovery IPv4 URL:soap.udp://239.255.255.250:PORT/

[0165] Discovery IPv6 URL: soap.udp://[FF02::C]:PORT/ (link scope)

[0166] System Discovery URL: the URL at which a given system waits fordiscovery messages. This URL is normally bound to a TCP based SOAPtransport, i.e. HTTP or TCP. By default, the URL is set tohttp://<name>:PORT/, where <name> is the name of the local system.

[0167] Discovery URI: The conventional discovery URI identifying theentity to which discovery messages are destined carried as part of<disc:To>SOAP header block. This URI in combination with the abovediscovery URLs (transport addresses) identifies the discovery endpoint.This URI is fixed by convention to behttp://schemas.upnp.org/2003/01/discovery/discovery-uri.

[0168] Discovery spreading timer: a timer used to delay some actions bya random interval, set by default to 1 second.

[0169] Discovery query timer: a timer used when waiting for responses,set by default to 2 seconds.

[0170] Configured discovery server URL: the URL of a discovery server,as explicitly configured in a responder or a client.

[0171] Discovered discovery server URL: the URL of a discovery server,as dynamically discovered by a discovery client.

[0172] Discovery Max-Hops: the number of links that can be spanned by amulticast message, or by a message sent in response to a multicastmessage. The value is fixed to 1.

[0173] Behavior of Discovery Responders.

[0174] Discovery responders 130-132 (FIG. 1) are engaged in three typesof operation: they announce their presence when they enter a network,they respond to discovery requests, and they send a ByeBye message whenthey depart a network. The behavior of these systems may be affected bythe configuration of a discovery server.

[0175] Configuration of a Discovery Server in a Discovery Responder.

[0176] Discovery responders may be configured to use a discovery servereither through explicit configuration, or, by using a DHCP “discoveryserver option.” In the presence of both a DHCP option and a configuredvalue, the discovery responder uses the configured value.

[0177] Discovery responders that also behave as discovery clients mayobtain a “discovered discovery server” URL. The presence or absence ofthis URL will not affect the behavior of the responder, i.e. the sendingof Announce and ByeBye messages or the processing of discovery requests.

[0178] Sending Announce Messages.

[0179] The discovery responders 130-132 send an announce message uponentering the network 120. The “entering of a network” event may bedetected through low level mechanisms, such as wireless beacons, orthrough a change in IP connectivity. The discovery responders also sendan announce message if their configuration changes, i.e. if the lastannounce message they sent carried a different configNumber than thecurrent value. The discovery responders may or may not need to send anAnnounce message following a change in IP address: if they followedrecommended practice, their description only includes host names in theURL, not IP addresses, and a change in IP address thus does not resultin a change of the configuration. However, in some cases, a change in IPaddress may be indicative of the device entering a new network, whichwarrants an Announce message.

[0180] Discovery responders 130-132 wait for a timer between detectingthis event and sending the announce message. This timer will be set to arandom value picked between 0 and a configured value T; by default, T isset to 1 second.

[0181] If the discovery responder has been configured to use a discoveryserver 140, the responder-will send the announce message to theconfigured URL of the server, normally using a TCP based transport. Ifthe responder has not been configured to use a discovery server, theannounce message will be sent using SOAP.UDP to the discovery IPv4 URL,if it is IPv4 capable, and to discovery IPv6 URL, if it is IPv6 capable.A dual stack responder will send the announce message over both IPv4 andIPv6. When sending a SOAP.UDP message over IPv4, the discoveryresponders set the IP TTL value to the discovery. Max-Hops value, inorder to limit propagation of the message.

[0182] Responders may repeat an announce message up to N=4 times, usingexponentially increasing random timers between each retransmission. Ifthe discovery server is configured, the system should stopretransmission as soon as it knows that a transmission has beensuccessful.

[0183]FIG. 9 shows a procedure (represented in pseudo-code form) used inthe discovery responder to send an announcement message.

[0184] The repeated messages should specify the same<disc:MessageID>SOAP header block so as to support detection ofduplicate messages, as discussed in the section on elimination ofduplicate messages below.

[0185] In secure environments, the discovery responders 130-132 canauthenticate announce messages by inserting WS security extensions inthe SOAP headers. Since announce messages can be used in replay attacks,the WS security extensions include appropriate “anti replay”protections.

[0186] Processing of Discovery Queries.

[0187] The discovery responders 130-132 (FIG. 1) wait for incomingdiscovery queries (find messages). The URL at which they wait for thesequeries depend upon their state of configuration:

[0188] Regardless of their configuration state, all discovery responderswait for find messages at their System Discovery URL.

[0189] Responders that are not explicitly configured with a discoveryserver address wait for find messages at the discovery IPv4 URL if theyare IPv4 capable, at the discovery IPv6 URL if they are IPv6 capable,and at both addresses if they are dual-stack.

[0190] Discovery responders that also behave as discovery clients mayhave discovered a discovery server URL by means other thanconfiguration; this discovery will not affect their behavior.

[0191] In order to avoid duplicate responses, the discovery respondersshould maintain a list of “already processed” find messages, asdiscussed in the section on elimination of duplicate messages below.

[0192] The discovery responders process find messages as follows:

[0193] 1. If the find message is received through the discovery IPv4 URLor the discovery IPv6 URL, determine whether this is a new find messageor a duplicate, as discussed in the section on elimination of duplicatemessages below; if a duplicate, ignore the find message.

[0194] 2. If secure operation is requested, check that the credentialsspecified in the find message are valid; if this is not the case, ignorethe find message.

[0195] 3. Determine the return address from the <disc:ReplyTo> headerblock, as specified in section on specification of the contact addressbelow.

[0196] 4. Check that the return address is compatible with securityparameters (see below). If this is not the case, ignore the findmessage.

[0197] 5. Determine whether the local device or a local service matchesthe find message.

[0198] 6. If there is no match, stop further processing of the findmessage, if it was received through the discovery IPv4 URL or thediscovery IPv6 URL after adding the find message identifier to the listof already processed messages; prepare an empty find response if it wasreceived through the local System Discovery URL.

[0199] 7. If the find message was not received through the local SystemDiscovery URL, wait for a random time interval, picked at random between0 and the standard discovery spreading timer.

[0200] 8. Send the find response to the return address.

[0201] 9. If the transmission of the find response was successful, addthe find message identifier to the list of already processed findmessages.

[0202] The duplicate determination in step 1 relies on the MessageIDparameter of the SOAP header block. If this identifier is not present inthe SOAP header, the find message will not be considered a duplicate;even if a find response is sent, step 9 will not be performed. If theidentifier is present, the responder will test for duplicate asdiscussed in the section on elimination of duplicate messages below.

[0203] Step 2, secure operation, is requested when some of theresponder's information is considered protected. Credentials, ifpresent, are carried out using the “web service security” (WS-Security)extensions (discussed above) in the SOAP header.

[0204] The contact information mentioned in step 3 is encoded in the<disc:ReplyTo> SOAP header block. If this element is absent, the contactaddress will be set according to the rules specified in the section onSpecification of the Contact Address below.

[0205] The return address checks in step 4 helps to prevent use ofad-hoc service discovery protocol for mounting denial of service attacksagainst third parties. The checks may be bypassed if the source has beenidentified as trusted during step 3. If the source has not beenidentified as trusted, the following checks should apply:

[0206] The IP address at which the find response is sent must be thesame address as the source address of the find message;

[0207] If the find message was not received over a TCP based transport,e.g. if was received through the SOAP.UDP UPNP discovery IPv4 URL or theUPNP discovery IPv6 URL, then the IP address should belong to the locallink.

[0208] If these conditions are not verified, the find message should beignored. We should note that testing that an address “belongs to thelocal link” is not always possible; it is easy to do when the addresshas a limited scope (e.g. IPv6 site local address) but may be harder inthe case of IPv4 or IPv6 global addresses. When the test cannot beperformed, the responder may decide to proceed with the find message ifit can assure that the find response will not be propagated more thanthe allowed number of hops, e.g. by setting the IP TTL to the discoveryMax-Hops value for the response connection.

[0209] The procedure described above can be varied as a localimplementation decision. For example, step 5, which determines whetherthere is a find response to be sent, can be performed immediately, so adevice minimizes the amount of resources consumed by find messages towhich it will not respond.

[0210] Sending ByeBye Messages.

[0211] The discovery responders 130-132 may send a ByeBye message upondeparting the network 120, e.g. in a “polite shutdown” procedure.

[0212] If the discovery responder has been configured to use a discoveryserver, the responder will send the ByeBye message to the configured URLof the sender, normally using a TCP based transport. If the responderhas not been configured to use a discovery server, the ByeBye messagewill be sent using SOAP.UDP to the discovery IPv4 URL, if it is IPv4capable, and to discovery IPv6 URL, if it is IPv6 capable; a dual stackresponder sends the ByeBye message over both IPv4 and IPv6. When sendinga SOAP.UDP message over IPv4, the discovery responders set the TTL ofthe IP packet to the UPNP discovery Max-Hops value, in order to limitpropagation of the message.

[0213] Discovery responders may repeat the ByeBye message up to N=4times waiting a random amount of interval between 1 to 2 seconds betweenconsecutive messages so as to improve reception of the ByeBye message ina multicast environment. All of the repeated ByeBye messages shouldspecify same <disc:MessageID>SOAP header block, in order to enablereceivers to eliminate duplicate messages, as discussed in the sectionon elimination of duplicate messages below.

[0214] Discovery responders are by no means required to repeat theByeBye message 4 times. In fact, they are not even required to send asingle message.

[0215] Behavior of Discovery Clients.

[0216] Discovery clients 110-111, (FIG. 1) perform discovery of devicesand services by issuing find requests and waiting for find responses.They may also listen to Announce and ByeBye messages from responders.The behavior of these systems may be affected by the configuration of,or the discovery of, a discovery server.

[0217] Configuration in a Discovery Client of a Discovery Server.

[0218] Discovery clients 110-111 may be configured to use a discoveryserver through explicit configuration or by using the DHCP “discoveryserver option.” In the presence of both a DHCP option and a configuredvalue, the discovery client shall use the configured value.

[0219] Discovery of a Discovery Server

[0220] Discovery clients 110-111 (FIG. 1) that have not been configuredto use a discovery server may discover a server by using the ad-hocservice discovery protocol. In this case, the use of the discoveredserver is optional: the discovery clients may weight the risks of the“spoofed server” attack against the practicality of using the server. Inpractice, the discovery clients should only use a discovered discoveryserver if the find response from the discovery server was properlyauthenticated.

[0221] Discovery clients may also discover a discovery server byreceiving an announce message from a discovery server. Again, thediscovery clients should only use this information if the announcemessage is properly authenticated, or if it can be confirmed by theproperly authenticate response to a find message.

[0222] Sending Queries and Waiting for Responses.

[0223] When a discovery client wants to find devices or services on alocal network, the discovery client prepares and sends a find messageand then waits for find responses. The body of the find messagedocuments the query. The SOAP header may document a number ofextensions:

[0224] WS security extensions for authenticating the message,

[0225] Message identifier encoded as the <disc:MessageID>SOAP headerblock,

[0226] Time to live of the query encoded in the <disc:TTL>SOAP headerblock,

[0227] Contact address in the <disc:ReplyTo> element of the SOAP header.

[0228] The discovery client will use these extensions when appropriate,i.e. when operating in secure mode (under WS security), when sendingmessage over an unreliable transport such as SOAP.UDP (messageidentifier), or when a default time to live (TTL) of 30 second is toolong (time to live). If the client does not specify a contact address,it should be ready to receive responses at default local systemdiscovery URL, constructed as “http://<source>:PORT/, where <source> isthe IP address of the client and PORT is the Discovery port.

[0229] If a discovery server has been explicitly configured, thediscovery client sends find messages to that discovery server. If thetransmission of the find message fails, the discovery client considersthat the discovery service is unavailable.

[0230] If a discovery server has been dynamically discovered, thediscovery client tries to send find messages to that discovery server.If the transmission of the find message fails, the discovery client mayeither try to discover another discovery server and transmit the findmessage to that alternate server, or it may fall back to the ad hocoperation.

[0231] If no discovery server has been configured or discovered, or ifthe discovered discovery server is not available, the discovery clientsends (multicasts) a copy of the find message using SOAP.UDP to thediscovery IPv4 URL, if it is IPv4 capable, and to the discovery IPv6URL, if it is IPv6 capable; dual stack clients will send the findmessage over both IPv4 and IPv6. When sending a SOAP.UDP message overIPv4, the discovery client sets the IP TTL to the Discovery Max-Hopsvalue, in order to limit propagation of the message.

[0232] After sending the find message, the discovery client waits forfind responses. Find responses arrive at the specified URL in the findmessage. If the client has issued multiple simultaneous find messages,it will use the <disc:CorrelationID>SOAP header block of incoming findresponses to correlate these find responses with the original findmessages.

[0233] If the find message was sent to a discovery server, the discoveryprocess will complete after either:

[0234] The arrival of a find response from the server;

[0235] Or the elapsing of the discovery find timer, which indicates afailure of the discovery server.

[0236] If the find message was sent to a multicast address, thediscovery client may receive several find responses, from multiplediscovery responders. The discovery client does not know in advance howmany systems will respond, and can adopt one of the two followingbehaviors:

[0237] It may just wait for a sufficient number of find responses,

[0238] Or it may decide to repeat the find message several times, untilit is convinced that no further find responses will be received.

[0239] If the discovery client decides to repeat the find messageseveral times, it should use the same message identifier in all copiesof the find message, and wait an interval at least equal to thediscovery find timer between two repetitions.

[0240] Processing of Announce and ByeBye Messages

[0241] Discovery clients 110-111 may monitor Announce and ByeByemessages to maintain a list of the devices and services available on thenetwork 120 by listening to the discovery IPv4 URL, if they are IPv4capable, and to discovery IPv6 URL, if they are IPv6 capable; dual stackdiscovery clients monitor both addresses.

[0242] Discovery clients should be aware of the possible attacks byspoofed Announce or ByeBye messages, or by replayed Announce or ByeByemessage, and implement mitigations. In particular, the followingprecaution is applied if a discovery client decides to contact thedevice/service, for example to query its properties, after receiving anannounce message:

[0243] If the announce message was not received through a TCP basedtransport, wait for a random time interval picked at random between 0and the standard UPNP discovery spreading timer before contacting thedevice;

[0244] If the IP address at which the device will be contacted wasdeduced from a data element in the announce message, check that this IPaddress is trusted.

[0245] The definition of a trusted address is the same as the definitionused by responders responding to find messages. If the announce was notproperly authenticated and did not come from a trusted source, then: theIP address contacted must be the same address as the source address ofthe announce message; and the IP address must belong to the local link.If the client cannot easily determine whether the address belong to alocal link, it must assure that the contact message will not bepropagated outside of the local link, e.g. by setting the IPv4 TTL orthe IPv6 max-Hops parameter to the Discovery Max-Hops value for theconnection over which the contact message is sent.

[0246] Behavior of Discovery Servers.

[0247] The primary role of discovery servers 140 (FIG. 1) is to respondto queries issued by discovery clients 110-111 (FIG. 1). The discoveryservers maintain a database of discovered devices that are present onthe network 120, by a combination of:

[0248] Listening to Announce and ByeBye messages,

[0249] Issuing find messages to discover devices and services present inthe local network 120,

[0250] And possibly other means (e.g., explicit configuration, directoryservice or other discovery protocol).

[0251] Response to Discovery Queries

[0252] The discovery servers 140 wait for queries on:

[0253] The System Discovery URL used by for the service,

[0254] The discovery IPv4 URL if they are IPv4 capable, at the discoveryIPv6 URL if they are IPv6 capable, and at both addresses if they aredual-stack.

[0255] The processing of find messages by discovery servers is similarto the processing of find messages by discovery responders, with twoimportant differences:

[0256] If the discovery server receives a find message through thediscovery IPv4 URL or the discovery IPv6 URL (i.e., through multicast),the discovery server should respond to the find message if the findmessage matches the description of itself i.e. the discovery service;the discovery server may respond to other find messages with adescription of the discovery service, even if the find message is foranother type of service.

[0257] If the discovery server receives a find message through the localSystem Discovery URL, the server will respond with a list of entriesthat are present in the server's database and match the find message.

[0258] The purpose of the first rule is to allow dynamic discovery ofthe server. The second rule describes the essential difference between aserver and a responder. In secure environments, the list of entries willonly contain the information whose access can be authorized, based onthe credentials present in the find message.

[0259] Using SOAP

[0260] The ad-hoc service discovery protocol is executed by the exchangeof SOAP messages, following the specification of SOAP, which isdescribed in Box et al., “Simple Object Application Protocol (SOAP)1.1,” W3C Note 08 May 2000. The following sections discuss how discoveryclients, responders and servers are use SOAP. Specifically, the use ofSOAP bindings to the HTTP and SOAP.UDP transports, the default URL usedby the service, the use of UPnP-specific SOAP header blocks to eliminateduplicate messages and specify a reply URI, and the use of WS-Securityextensions to authenticate and possibly encrypt messages is discussed.

[0261] SOAP Bindings

[0262] SOAP messages may be carried over different types of transport.The W3C has so far specified two bindings of SOAP Version 1.2: SOAP overHTTP (described in Gudgin et al., “SOAP Version 1.2 Part 2: Adjuncts,”W3C Proposed Recommendation 07 May 2003) and SOAP over email. Discoveryclients, responders and servers implement the SOAP HTTP Binding and“conform to the SOAP 1.2 HTTP Binding.” Discovery clients, respondersand servers may implement other SOAP bindings as these bindings getstandardized.

[0263] In the ad-hoc service discovery protocol, some messages are sentover UDP multicast. There is not yet a standard binding of SOAP overUDP. The above discussion defines the SOAP.UDP scheme used in thisbinding. This scheme will only be used for the transmission of multicastmessages; not for “unicast” transmission of SOAP messages to a specifichost.

[0264] The SOAP.UDP Binding

[0265] The SOAP.UDP binding is minimally defined by specifying theSOAP.UDP packet format, the SOAP.UDP URL format, and the SOAP.UDPtransmission rules.

[0266] SOAP.UDP Packet Format

[0267] When using the SOAP.UDP binding, a SOAP message is transmitted bysending the XML encoded SOAP message in the payload of a UDP datagram;the XML text is encoded using UTF-8. There are no intermediate databetween the UDP header and the first character of the XML text.

[0268] SOAP.UDP URL Format

[0269] The URL at which SOAP.UDP messages are sent is encoded accordingto the following minimal syntax:

[0270] SoapUdpUrl=“soap.udp:” “//” Host “:” Port

[0271] Host=ipv4-address|“[” ipv6-address “]”

[0272] Port=1*5 Digit

[0273] The IPv4 address, if present, is encoded according to the “quaddot” notation, e.g. 127.0.0.1.

[0274] The IPv6 address, if present, is encoded according to the textualrepresentation of IPv6 addresses specified in RFC 2373, e.g.2001:234::5678:90AB:CEDF. The encapsulation of this address betweensquare brackets is in conformance with RFC 2732.

[0275] SOAP.UDP Transmission Rules

[0276] Discovery clients, responders and servers transmit SOAP.UDP bysending the message text as the payload of a UDP datagram. The IP andUDP header are constructed as follows:

[0277] Choice of IP version: IPv4 or IPv6, depending of the addressspecified in the SOAP.UDP URL.

[0278] IP Source address: appropriate IPv4 or IPv6 address of thesender.

[0279] Destination address: the IPv4 or IPv6 address encoded in theSOAP.UDP URL.

[0280] Source UDP port: a port chosen by the sender.

[0281] Destination UDP port: the port number specified in the SOAP.UDPURL.

[0282] UDP payload length: the length in bytes of the XML encoding

[0283] The use of an IP source address and source UDP port in a SOAP.UDPmessage does not imply that the sender is ready to receive SOAP UDPmessages at that same address and port. All responses to a SOAP.UDPmessage are sent, by default, to an HTTP URL, using a regular HTTP overTCP transport.

[0284] Elimination of Duplicate Messages

[0285] For reliability, messages transmitted over SOAP.UDP may berepeated, which often leads to duplicate reception. Duplicate receptionmay also result from the transmission of the same message throughmultiple channels, e.g. over IPv4 and over IPv6. It is important fordiscovery agents (i.e., discovery clients, discovery responders anddiscovery servers) to recognize duplicate messages as such, in order toas much as possible avoid duplicate processing and duplicatetransmission of responses.

[0286] In order to avoid duplicate responses, the discovery agentsmaintain a list of “already processed” SOAP messages. Each entry in thelist indicates a message identifier (MessageID) and a time to live(TTL); the entries are removed if the time to live has expired. Themessage identifier is encoded in the <disc:MessageID>SOAP header blockas a URI. By default, the time to live of an entry is set to 30 seconds;alternative value may be specified on a per message basis using the<disc:TTL>SOAP header block; receivers may however decide to cap thevalue at some preset maximum, in order to avoid having to keep trace ofany message for too long.

[0287] The list is managed as follows:

[0288] A new entry is added to the list after successfully processing amessage that was received on an unreliable transport, i.e. SOAP.UDP.

[0289] The list is consulted each time a message is received through theunreliable transport, SOAP.UDP; if the message identifier is alreadypresent in the list, the message is discarded without any furtherprocessing.

[0290] Entries are removed from the list when their time to liveexpires.

[0291] Systems preferably implement the list of already processedmessages carefully; such as by using list management techniques todiscard old entries if the size of the list exceeds the locally definedcapacity.

[0292] Specification of the Contact Address

[0293] There are at least two cases when the sender of a discoverymessage expects to be contacted by the recipient: after sending a findmessage, the discovery client expects to receive find response messagesfrom the responders; after sending an Announce message, a discoveryresponder may expect to receive find messages from discovery clients.The <disc:ReplyTo>SOAP header block can be used to encode the URL atwhich the sender of the find message expects to be contacted.

[0294] When the <disc:ReplyTo> header block is absent, the receivers ofthe message will contact the sender at the default system discovery URL,constructed as “http://<source>:PORT/”, where <source> is the IP addressof the client and PORT is the Discovery port.

[0295] Computing Device Structure

[0296] The above described ad-hoc service discovery protocol in thenetwork architecture 100 (FIG. 1) can be performed on any of a varietyof networked computing devices, including audio/video or othermultimedia recording/transmitting/receiving/or presenting devices(broadcast receivers, televisions, video players, cameras, etc.),computers (personal, workstation, server, handheld, laptop, tablet, orother mobile), telephones, office equipment (printers, copiers,scanners, fax), security systems, home appliances (lighting, heating,ventilation, air conditioning, door openers, kitchen appliances, etc.),as a few general examples. The ad-hoc service discovery protocol can beimplemented in hardware circuitry, as well as in software 880 of adevice connectivity protocol (e.g., UPNP) executing within a computer orother computing environment, such as shown in FIG. 10.

[0297]FIG. 10 illustrates a generalized example of a suitable computingenvironment 800 in which the described techniques can be implemented.The computing environment 800 is not intended to suggest any limitationas to scope of use or functionality of the invention, as the presentinvention may be implemented in diverse general-purpose orspecial-purpose computing environments.

[0298] With reference to FIG. 10, the computing environment 800 includesat least one processing unit 810 and memory 820. In FIG. 8, this mostbasic configuration 830 is included within a dashed line. The processingunit 810 executes computer-executable instructions and may be a real ora virtual processor. In a multi-processing system, multiple processingunits execute computer-executable instructions to increase processingpower. The memory 820 may be volatile memory (e.g., registers, cache,RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), orsome combination of the two. The memory 820 stores software 880implementing the device connectivity protocol, including the ad-hocservice discovery protocol.

[0299] A computing environment may have additional features. Forexample, the computing environment 800 includes storage 840, one or moreinput devices 850, one or more output devices 860, and one or morecommunication connections 870. An interconnection mechanism (not shown)such as a bus, controller, or network interconnects the components ofthe computing environment 800. Typically, operating system software (notshown) provides an operating environment for other software executing inthe computing environment 800, and coordinates activities of thecomponents of the computing environment 800.

[0300] The storage 840 may be removable or non-removable, and includesmagnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, orany other medium which can be used to store information and which can beaccessed within the computing environment 800. The storage 840 storesinstructions for the device connectivity software 880, including thead-hoc service discovery protocol.

[0301] The input device(s) 850 (e.g., for devices operating as a controlpoint in the device connectivity architecture 100) may be a touch inputdevice such as a keyboard, mouse, pen, or trackball, a voice inputdevice, a scanning device, or another device that provides input to thecomputing environment 800. For audio, the input device(s) 850 may be asound card or similar device that accepts audio input in analog ordigital form, or a CD-ROM reader that provides audio samples to thecomputing environment. The output device(s) 860 may be a display,printer, speaker, CD-writer, or another device that provides output fromthe computing environment 800.

[0302] The communication connection(s) 870 enable communication over acommunication medium to another computing entity. The communicationmedium conveys information such as computer-executable instructions,audio/video or other media information, or other data in a modulateddata signal. A modulated data signal is a signal that has one or more ofits characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media include wired or wireless techniques implementedwith an electrical, optical, RF, infrared, acoustic, or other carrier.

[0303] The ad-hoc service discovery protocol can be described in thegeneral context of computer-readable media. Computer-readable media areany available media that can be accessed within a computing environment.By way of example, and not limitation, with the computing environment800, computer-readable media include memory 820, storage 840,communication media, and combinations of any of the above.

[0304] The techniques herein can be described in the general context ofcomputer-executable instructions, such as those included in programmodules, being executed in a computing environment on a target real orvirtual processor. Generally, program modules include routines,programs, libraries, objects, classes, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or splitbetween program modules as desired in various embodiments.Computer-executable instructions for program modules may be executedwithin a local or distributed computing environment.

[0305] For the sake of presentation, the detailed description uses termslike “determine,” “generate,” “adjust,” and “apply” to describe computeroperations in a computing environment. These terms are high-levelabstractions for operations performed by a computer, and should not beconfused with acts performed by a human being. The actual computeroperations corresponding to these terms vary depending onimplementation.

[0306] In view of the many possible embodiments to which the principlesof our invention may be applied, we claim as our invention all suchembodiments as may come within the scope and spirit of the followingclaims and equivalents thereto.

We claim:
 1. A method of reliably discovering devices and services withad-hoc and server-based operation in a network environment of devicesacting as discovery clients and discovery responders, the methodcomprising: detecting by a discovery client whether a discovery serveris present; in a detected absence of any discovery server, conductingdiscovery by the discovery client as a multicast operation; in adetected presence of any discovery server, suppressing by the discoveryclient of its multicast operation and conducting discovery by thediscovery client directed to the detected discovery server; andcontinuing by the discovery responders to respond to multicast discoveryregardless of the presence or absence of the discovery server in thenetwork environment.
 2. The method of claim 1, wherein the detectingcomprises sending by the discovery client of a discovery query as amulticast operation to find any discovery server in the networkenvironment.
 3. A method of reliable multicast suppression in servicediscovery on ad-hoc networks, comprising: sending a multicast discoveryquery for discovery servers by a discovery client on a network to findany discovery server present within a scope on the network; receiving bythe discovery client any response to the multicast discovery query; uponreceiving a response of a discovery server to the multicast discoveryquery, suppressing sending further multicast discovery queries fordevice services by the discovery client and sending further discoveryqueries for device services by the discovery client directly to thediscovery server, while the discovery server remains present on thenetwork; and in absence of any response to the multicast discoveryquery, sending the any further discovery queries for device services bythe discovery client as multicast discovery queries on the network. 4.The method of claim 3, wherein discovery responders continue to respondto multicast discovery queries for device services matching therespective discovery responders from the discovery client irrespectiveof the discovery server being present on the network.
 5. A computingdevice operating as a discovery client in a network architecture for adiscovery protocol capable of ad-hoc and server-based operation, thecomputing device comprising: a memory storing software programming foran ad-hoc discovery protocol; and a processor operating to execute thesoftware programming in the memory; wherein the software programmingcomprises: programming code for switching the discovery client betweenserver-based and ad-hoc discovery modes when a discovery server isdetermined to be present or absent, respectively, in a network in whichthe computing device is operating; server-based discovery modeprogramming code for sending discovery queries of the discovery clientdirectly to the discovery server determined to be present in thenetwork; and ad-hoc discovery mode programming code for sendingdiscovery queries of the discovery client as a multicast transmission todiscovery responders in the network.
 6. The computing device of claim 5,wherein the software programming further comprises programming code fordetecting the presence or absence of a discovery server in the network.7. The computing device of claim 6, wherein the programming code fordetecting comprises programming code for sending a multicast discoveryquery to find discovery servers present in the network.
 8. Acomputer-readable media having computer-readable software programmingthereon for executing on a discovery client in a network architecture ofa discovery protocol capable of server-based and ad-hoc discovery, thesoftware programming comprising: programming code for switching thediscovery client between server-based and ad-hoc discovery modes when adiscovery server is determined to be present or absent, respectively, ina network in which the computing device is operating; server-baseddiscovery mode programming code for sending discovery queries of thediscovery-client directly to the discovery server determined to bepresent in the network; and ad-hoc discovery mode programming code forsending discovery queries of the discovery client as a multicasttransmission to discovery responders in the network.
 9. Thecomputer-readable media of claim 8, wherein the software programmingfurther comprises programming code for detecting the presence or absenceof a discovery server in the network.
 10. The computer-readable media ofclaim 9, wherein the programming code for detecting comprisesprogramming code for sending a multicast discovery query to finddiscovery servers present in the network.
 11. A distributed system ofnetworked computing devices compliant with an ad-hoc service discoveryprotocol, the distributed system comprising: at least one networkedcomputing device operating as a discovery client according to a networkarchitecture of the ad-hoc service discovery protocol, the discoveryclient having a server-based discovery mode and an ad-hoc discoverymode, the discovery client operating to determine whether any discoveryserver is present or absent in a network and switch to the server-baseddiscovery mode or ad-hoc discovery mode, respectively, according to thedetermination, the discovery client operating in ad-hoc discovery modeto send discovery queries as multicast transmissions and operating inserver-based discovery mode to suppress multicast transmission ofdiscovery requests by the discovery client; and at least one networkedcomputing device operating as a discovery responder according to thenetwork architecture of the ad-hoc service discovery protocol, thediscovery responder operating regardless of presence or absence of adiscovery server in the network to respond to multicast transmissions ofdiscovery queries matching the discovery responder.
 12. The distributedsystem of claim 11 wherein the discovery client has a configured mode,the discovery client operating in the configured mode to suppressmulticast transmission of discovery requests by the discovery client andsend such discovery requests directly to a specified discovery serverspecified in its configuration.
 13. The distributed system of claim 11wherein the discovery responder has a configured mode, the discoveryresponder operating in the configured mode to suppress response tomulticast transmission of discovery requests.
 14. A method ofdiscovering device services in ad-hoc and server-managed networks ofcomputing devices, the method comprising: when connected in an ad-hocnetwork, sending discovery queries as a multicast transmission from adiscovery client computing device; and when connected in aserver-managed network having a discovery server, sending discoveryqueries from the discovery client computing device as a directedtransmission to the discovery server using a networking protocol thatguarantees message delivery.
 15. The method of claim 14 furthercomprising: responding to discovery queries received as multicasttransmissions by a computing device that match device services of thecomputing device regardless of whether connected in the ad-hoc orserver-managed network.
 16. The method of claim 14 wherein thenetworking protocol is the transmission control protocol (TCP).
 17. Acomputer-readable media having a software program thereon executable ona computing device to perform a method of discovering device services inad-hoc and server-managed networks of computing devices, the methodcomprising: when the computing device is connected in an ad-hoc network,sending discovery queries as a multicast transmission from the computingdevice; and when the computing device is connected in a server-managednetwork having a discovery server, sending discovery queries from thecomputing device directly to the discovery server using a networkingprotocol that guarantees message delivery.
 18. The computer-readablemedia of claim 17 wherein the networking protocol is the transmissioncontrol protocol (TCP).
 19. A computing device for discovering deviceservices in ad-hoc and server-managed networks of computing devices, themethod comprising: means for, when connected in an ad-hoc network,sending discovery queries as a multicast transmission from a discoveryclient computing device; and means for, when connected in aserver-managed network having a discovery server, sending discoveryqueries from the discovery client computing device as a directedtransmission to the discovery server using a networking protocol thatguarantees message delivery.
 20. The computing device of claim 19wherein the networking protocol is the transmission control protocol(TCP).
 21. A method of discovering device services in an ad-hocnetworking environment of computing devices acting as discovery clientsand discovery responders, wherein a discovery client sends a discoveryquery message as a multicast transmission one or more times, thediscovery query message containing a message identifier, the methodcomprising: maintaining a list of already processed messages by adiscovery responder according to message identifier of the alreadyprocessed messages; receiving the discovery query message by a discoveryresponder; determining based on the message identifier of the discoveryquery message and the discovery responder's already processed messageslist whether the discovery query message is newly received or aduplicate of a previously processed discovery query; if the discoveryquery message is determined to be newly received: sending a response tothe discovery query if the query is a match to a device service of thediscovery responder; and adding an entry for the discovery query messageto the discovery responder's already processed messages list; and if thediscovery query message is determined to be a duplicate, not processingthe discovery query of the discovery query message.
 22. The method ofclaim 21 wherein the discovery query message further contains a timeparameter indicative to a sending time period in which the discoveryclient sends the discovery query message one or more times, the methodfurther comprising: when adding an entry for the discovery querymessage, determining by the discovery responder a receiving time periodduring which transmissions of the discovery query message may bereceived by the discovery responder based on the time parameter; andinserting data representing the receiving time period in the entry;wherein the determining whether the discovery query message is newlyreceived or duplicate further comprises determining whether the receiveddiscovery query message was received within the receiving time periodrepresented in an entry in the already processed message list with amatching message identifier.
 23. The method of claim 22 furthercomprising removing entries from the discovery responder's list ofalready processed messages after the receiving time period is expired.24. A method of discovering device services in an ad-hoc networkingenvironment of computing devices acting as discovery clients anddiscovery responders, the method comprising: encoding by a discoveryclient a message identifier and a time parameter indicative of a sendingtime interval in a discovery query message; and sending by the discoveryclient the discovery query message as a multicast transmission one ormore times within the sending time interval.
 25. The method of claim 24further comprising: maintaining a list of already processed messages bya discovery responder according to message identifier of the alreadyprocessed messages, in which a receiving time period in which duplicatesof respective already processed messages may be received is indicated;receiving the discovery query message by a discovery responder;determining based on the message identifier of the discovery querymessage and the receiving time periods indicated in the discoveryresponder's already processed messages list whether the discovery querymessage is newly received or a duplicate of a previously processeddiscovery query; if the discovery query message is determined to benewly received: sending a response to the discovery query if the queryis a match to a device service of the discovery responder; and adding anentry for the discovery query message to the discovery responder'salready processed messages list indicating the receiving time period forthe discovery query message based on the time parameter; and if thediscovery query message is determined to be a duplicate, not processingthe discovery query of the discovery query message.
 26. The method ofclaim 25 further comprising removing entries from the discoveryresponder's list of already processed messages after the receiving timeperiod is expired.
 27. A computing device operating as a discoveryclient in a network architecture for an ad-hoc discovery protocol, thecomputing device comprising: a memory storing software programming foran ad-hoc discovery protocol; and a processor operating to execute thesoftware programming in the memory; wherein the software programmingcomprises: programming code for encoding by a discovery client a messageidentifier and a time parameter indicative of a sending time interval ina discovery query message; and programming code for sending by thediscovery client the discovery query message as a multicast transmissionone or more times within the sending time interval.
 28. A computingdevice operating as a discovery responder in a network architecture foran ad-hoc discovery protocol, the computing device comprising: a memorystoring software programming for an ad-hoc discovery protocol; and aprocessor operating to execute the software programming in the memory;wherein the software programming comprises: programming code formaintaining a list of already processed messages by the discoveryresponder according to message identifier of the already processedmessages; programming code for receiving a discovery query message froma discovery client by the discovery responder; programming code forprocessing the received discovery query message, wherein the processingcomprises: determining based on the message identifier of the discoveryquery message and the discovery responder's already processed messageslist whether the discovery query message is newly received or aduplicate of a previously processed discovery query; if the discoveryquery message is determined to be newly received: sending a response tothe discovery query if the query is a match to a device service of thediscovery responder; and adding an entry for the discovery query messageto the discovery responder's already processed messages list; and if thediscovery query message is determined to be a duplicate, not processingthe discovery query of the discovery query message.
 29. A computingdevice operating as a discovery responder in a network architecture foran ad-hoc discovery protocol, the computing device comprising: a memorystoring software programming for an ad-hoc discovery protocol; and aprocessor operating to execute the software programming in the memory;wherein the software programming comprises: programming code formaintaining a list of already processed messages by a discoveryresponder according to message identifier of the already processedmessages, in which a receiving time period in which duplicates ofrespective already processed messages may be received is indicated;programming code for receiving a discovery query message from adiscovery client by the discovery responder; programming code forprocessing the received discovery query message, wherein the processingcomprises: determining based on the message identifier of the discoveryquery message and the receiving time periods indicated in the discoveryresponder's already processed messages list whether the discovery querymessage is newly received or a duplicate of a previously processeddiscovery query; if the discovery query message is determined to benewly received: sending a response to the discovery query if the queryis a match to a device service of the discovery responder; and adding anentry for the discovery query message to the discovery responder'salready processed messages list indicating the receiving time period forthe discovery query message based on the time parameter; and if thediscovery query message is determined to be a duplicate, not processingthe discovery query of the discovery query message.
 30. Acomputer-readable media having a software program thereon executable ona networked computing device acting as a discovery client in an ad-hocnetworking environment according to an ad-hoc discovery protocol toeffect a method of discovering device services on a network, the methodcomprising: encoding by a discovery client a message identifier and atime parameter indicative of a sending time interval in a discoveryquery message; and sending by the discovery client the discovery querymessage as a multicast transmission one or more times within the sendingtime interval.
 31. A computer-readable media having a software programthereon executable on a networked computing device acting as a discoveryresponder in an ad-hoc networking environment according to an ad-hocdiscovery protocol wherein a discovery client sends a discovery querymessage as a multicast transmission one or more times within a sendingtime interval to effect a method of discovering device services on anetwork, the discovery query message including a message identifier anda time parameter indicative of the sending time interval, the methodcomprising: maintaining a list of already processed messages by thediscovery responder according to message identifier of the alreadyprocessed messages, in which a receiving time period in which duplicatesof respective already processed messages may be received is indicated;receiving the discovery query message by a discovery responder;determining based on the message identifier of the discovery querymessage and the receiving time periods indicated in the discoveryresponder's already processed messages list whether the discovery querymessage is newly received or a duplicate of a previously processeddiscovery query; if the discovery query message is determined to benewly received: sending a response to the discovery query if the queryis a match to a device service of the discovery responder; and adding anentry for the discovery query message to the discovery responder'salready processed messages list indicating the receiving time period forthe discovery query message based on the time parameter; and if thediscovery query message is determined to be a duplicate, not processingthe discovery query of the discovery query message.
 32. Thecomputer-readable media of claim 31 wherein the method further comprisesremoving entries from the discovery responder's list of alreadyprocessed messages after the receiving time period is expired.
 33. Amethod of discovering device services in an ad-hoc networkingenvironment of computing devices acting as discovery clients anddiscovery responders, the method comprising: at boot-time of a discoveryresponder, generating a new value of a stateless boot time parameter ofthe discovery responder if operating state of the discovery respondersince previous operation has been lost; at time of the discoveryresponder joining a network, creating an announcement message by thediscovery responder for a device service provided by the discoveryresponder, the announcement message including the stateless boot timeparameter; and sending the announcement message by the discoveryresponder as a multicast transmission on the network.
 34. The method ofclaim 33 wherein generating the new value comprises incrementing a bootcounter to provide the new value of the stateless boot time parameter.35. The method of claim 33 wherein generating the new value comprisesreading a value from a real-time clock to provide the new value of thestateless boot time parameter.
 36. A computing device operating as adiscovery responder in a network architecture for an ad-hoc discoveryprotocol, the computing device comprising: a memory storing softwareprogramming for an ad-hoc discovery protocol; and a processor operatingto execute the software programming in the memory; wherein the softwareprogramming comprises: programming code executing at boot-time of thediscovery responder for generating a new value of a stateless boot timeparameter of the discovery responder if operating state of the discoveryresponder since previous operation has been lost; programming codeexecuting at time of the discovery responder joining a network forcreating an announcement message by the discovery responder for a deviceservice provided by the discovery responder, the announcement messageincluding the stateless boot time parameter, and sending theannouncement message by the discovery responder as a multicasttransmission on the network.
 37. A computer-readable media having asoftware program thereon executable on a networked computing deviceacting as a discovery responder in an ad-hoc networking environmentaccording to an ad-hoc discovery protocol to effect a method comprising:at boot-time of a discovery responder, generating a new value of astateless boot time parameter of the discovery responder if operatingstate of the discovery responder since previous operation has been lost;at time of the discovery responder joining a network, creating anannouncement message by the discovery responder for a device serviceprovided by the discovery responder, the announcement message includingthe stateless boot time parameter; and sending the announcement messageby the discovery responder as a multicast transmission on the network.38. A method of discovering device services in an ad-hoc networkingenvironment of computing devices acting as discovery clients anddiscovery responders, wherein a discovery responder sends a multicastannouncement message for a device service and containing a statelessboot time parameter, the method comprising: maintaining cache data ofdiscovered device services in a discovery client; receiving theannouncement message from the discovery responder by a discovery client;determining by the discovery client whether the device service of theannouncement message matches the cache data; and if so, determiningwhether the device service has lost operational state based on thestateless boot time parameter of the announcement message and the cachedata.
 39. A computing device operating as a discovery client in anetwork architecture for an ad-hoc discovery protocol, the computingdevice comprising: a memory storing software programming for an ad-hocdiscovery protocol; and a processor operating to execute the softwareprogramming in the memory; wherein the software programming comprises:programming code for maintaining cache data of discovered deviceservices in a discovery client, receiving the announcement message fromthe discovery responder by a discovery client, determining by thediscovery client whether the device service of the announcement messagematches the cache data, and if so, determining whether the deviceservice has lost operational state based on the stateless boot timeparameter of the announcement message and the cache data.
 40. Acomputer-readable media having a software program thereon executable ona networked computing device acting as a discovery responder in anad-hoc networking environment according to an ad-hoc discovery protocolto effect a method comprising: maintaining cache data of discovereddevice services in a discovery client; receiving the announcementmessage from the discovery responder by a discovery client; determiningby the discovery client whether the device service of the announcementmessage matches the cache data; and if so, determining whether thedevice service has lost operational state based on the stateless boottime parameter of the announcement message and the cache data.
 41. Amethod of discovering device services in an ad-hoc networkingenvironment of computing devices acting as discovery clients anddiscovery responders, the method comprising: upon a discovery responderjoining a network, sending an announcement message of a device serviceon the discovery responder by the discovery responder as a multicasttransmission, wherein the announcement message contains an end pointidentifier indicative of an identity of the discovery responder and aconfiguration number parameter indicative of a configuration of thediscovery responder; upon a change in configuration of the discoveryresponder, generating a new value of the configuration number parameterby the discovery responder; and sending a further announcement messageof the device service by the discovery responder as a multicast message,wherein the further announcement message contains the end pointidentifier and the configuration number parameter having the new value.42. The method of claim 41 further comprising: maintaining cache data ofdiscovered device services by a discovery node; receiving by thediscovery node an announcement message; determining whether aconfiguration of any discovered device service represented in the cachedata has changed based on the cache data for that discovered deviceservice matching the endpoint identifier contained in the announcementmessage but not the configuration number parameter contained in theannouncement message; and if so, retrieving an updated device servicedescription for that discovered device service from the discoveryresponder, and updating the cache data based on the retrieved deviceservice description.
 43. The method of claim 42 wherein the discoverynode is one of a discovery client or a discovery server.
 44. A method ofdiscovering device services in an ad-hoc networking environment ofcomputing devices acting as discovery clients and discovery responders,wherein discovery responders send a multicast announcement messagecontaining an endpoint identifier and configuration number, the methodcomprising: maintaining cache data of discovered device services by adiscovery node; receiving by the discovery node an announcement message;determining whether a configuration of any discovered device servicerepresented in the cache data has changed based on the cache data forthat discovered device service matching the endpoint identifiercontained in the announcement message but not the configuration numberparameter contained in the announcement message; and if so, retrievingan updated device service description for that discovered device servicefrom the discovery responder, and updating the cache data based on theretrieved device service description.
 45. A distributed system ofnetworked computing devices compliant with an ad-hoc service discoveryprotocol, the distributed system comprising: at least one networkedcomputing device operating as a discovery responder according to anetwork architecture of the ad-hoc service discovery protocol, thediscovery responder generating a new configuration number upon a changein its configuration and sending an announcement message containing anendpoint identifier and the new configuration number as a multicasttransmission; and at least one networked computing device operating as adiscovery node according to the network architecture of the ad-hocservice discovery protocol, the discovery node having a cache ofdiscovered device service descriptions, and operating upon receiving theannouncement message to determine whether a device service representedin a discovered device service description in the cache matching theendpoint identifier of the announcement message has changedconfiguration based on the configuration number of the announcementmessage.
 46. A computer-readable media having a software program thereonexecutable on a networked computing device acting as a discoveryresponder in an ad-hoc networking environment according to an ad-hocdiscovery protocol to effect a method comprising: upon a discoveryresponder joining a network, sending an announcement message of a deviceservice on the discovery responder by the discovery responder as amulticast transmission, wherein the announcement message contains an endpoint identifier indicative of an identity of the discovery responderand a configuration number parameter indicative of a configuration ofthe discovery responder; upon a change in configuration of the discoveryresponder, generating a new value of the configuration number parameterby the discovery responder; and sending a further announcement messageof the device service by the discovery responder as a multicast message,wherein the further announcement message contains the end pointidentifier and the configuration number parameter having the new value.47. A computer-readable media having a software program thereonexecutable on a networked computing device to effect a method, thenetworked computing device acting as a discovery node in an ad-hocnetworking environment according to an ad-hoc discovery protocol whereindiscovery responders send a multicast announcement message containing anendpoint identifier and configuration number, the method comprising:maintaining cache data of discovered device services by a discoverynode; receiving by the discovery node an announcement message;determining whether a configuration of any discovered device servicerepresented in the cache data has changed based on the cache data forthat discovered device service matching the endpoint identifiercontained in the announcement message but not the configuration numberparameter contained in the announcement message; and if so, retrievingan updated device service description for that discovered device servicefrom the discovery responder, and updating the cache data based on theretrieved device service description.
 48. A method of discovering pagednumbers of device services in a networking environment of computingdevices, the method comprising: sending a discovery query by a discoveryclient to a discovery server on a network to find device servicesmatching certain find criteria, the discovery query specifying a sizelimit parameter and passing a page context parameter; returning by thediscovery server a response to the discovery query for a number ofdevice services matching the find criteria up to the size limitparameter and returning the page context parameter, the page contextparameter being set to identify a context state of the discoveryserver's response to the discovery query; and repeating the steps ofsending the discovery query and returning the response, wherein thefurther responses by the discovery server return further incrementalsets of devices services matching the find criteria up to the size limitparameter specified in the discovery client's preceding discovery query.49. The method of claim 48 wherein the discovery queries sent by thediscovery client in different iterations specify different values of thesize limit parameter.
 50. The method of claim 48 further comprisingreturning an empty page context parameter by the discovery server in aresponse to an iteration of the discovery query to indicate an absenceof further device services matching the find criteria.
 51. The method ofclaim 48 further comprising specifying by the discovery client azero-valued size limit parameter in a final iteration of sending thediscovery request to indicate no further query iterations areforthcoming from the discovery client.
 52. A distributed system ofnetworked computing devices compliant with an ad-hoc service discoveryprotocol, the distributed system comprising: at least one networkedcomputing device operating as a discovery client according to a networkarchitecture of the ad-hoc service discovery protocol, the discoveryclient sending a discovery query to a discovery server on a network tofind device services matching certain find criteria, the discovery queryspecifying a size limit parameter and passing a page context parameter;a networked computing device operating as the discovery server accordingto the network architecture of the ad-hoc service discovery protocol,the discovery server returning a response to the discovery query for anumber of device services matching the find criteria up to the sizelimit parameter and returning the page context parameter, the pagecontext parameter being set to identify a context state of the discoveryserver's response to the discovery query; and wherein the discoveryclient and discovery server repeat the steps of sending the discoveryquery and returning the response, and the discovery server returnsfurther incremental sets of devices services matching the find criteriaup to the size limit parameter specified in the discovery client'spreceding discovery query in the further responses.
 53. Acomputer-readable media having a software program thereon executable ona networked computing device to effect a method, the networked computingdevice acting as a discovery server in a networking environmentaccording to a discovery protocol wherein discovery clients sendsuccessive iterations of a discovery query to find device servicesmatching certain find criteria and specifying a size limit parameter andpassing a page context parameter, the method comprising: returning aresponse to the discovery query for a number of device services matchingthe find criteria up to the size limit parameter and returning the pagecontext parameter set to identify a context state of the discoveryserver's response to the discovery query; and in response to furtheriterations of the discovery query, returning further responses to thediscovery query for further incremental sets of devices servicesmatching the find criteria up to the size limit parameter specified inthe iteration of the discovery query.
 54. The computer-readable media ofclaim 48 wherein the method further comprises returning an empty pagecontext parameter in a response to an iteration of the discovery queryto indicate an absence of further device services matching the findcriteria.
 55. A computer-readable media having a software programthereon executable on a networked computing device acting as a discoveryclient in a networking environment according to a discovery protocol toeffect a method comprising iteratively sending a discovery query by adiscovery client to a discovery server on a network to find deviceservices matching certain find criteria, the discovery query specifyinga size limit parameter and passing a page context parameter to control anumber of matching device services returned by the discovery server inresponse to the discovery query.